In the computer industry the term “crash” is defined as the sudden failure of a software application or operating system, or of a hardware device such as a hard disk. While a software crash usually creates an interruption in service, the dreaded hard disk crash also tends to cause the loss of data. Due to the mechanical nature of a fast-spinning disk drive (e.g., 10,000 RPM), crashes are usually permanent and the need for data protection becomes critical.
Along with data errors that occur due to outright drive failure, expressed as a mean time between failure (MTBF), drives also experience bit errors over the amount of data read, expressed as a bit error rate (BER). Other errors that can result in seek, read and write failures are usually masked by successful retries. Since many drives now come with MTBF's upward of one million hours, BER's on the order of 1 in 1×1015 and warranties up to 5 years, it makes economic sense for the vendors to be able to distinguish between a drive that has failed from one that is merely “having occasional trouble.” To reduce warranty replacement costs, drives hedge against excessive “failures” by employing many internal data recovery mechanisms, including error correction, retries, and sector remapping. Only when a drive exceeds its retry count and runs out of sectors for remapping is it considered “failed.”
Because of the need for deterministic data performance, video server designs usually cannot afford to allow drives the luxury to attempt all of the internal data correction mechanisms designed to conceal errors. Retries need to be limited and managed at a systemic level, and problematic drives generally are not acceptable.
Drive specifications also typically specify an annualized failure rate (AFR), which is equal to the operational duty cycle multiplied by the number of hours in a year and divided by the MTBF. Drives are usually divided into 3 classes, namely desktop, notebook and enterprise. Although more costly, only enterprise or server class drives are specified around a 100% duty cycle. So, a server drive with an MTBF of 1,000,000 hours would have an AFR of 0.876%, while a drive with an MTBF of 1,500,000 hours would have an AFR of 0.584%.
As systems increase in performance, size, and complexity, drive failure and error handling become a critical issue to video server design. Assuming a drive has a BER of 1 per 1×1015 (errors per bits read), as data rates increase, the error frequency approaches 1 every few hours. Since even a single uncorrected bit error in a critical data location may result in an unacceptable video anomaly, it is typically necessary to implement some form of data protection.
One disk drive configuration that is used to help guard against data loss is the redundant array of independent drives (RAID) configuration. Generally speaking, in a RAID data is divided and/or replicated among multiple hard disk drives, which can lead to increased data reliability as well as increased input/output (I/O) performance.
Various levels of RAID configurations have been developed, and different RAID levels take advantage of different storage/data protection techniques. For example, some RAIDs employ “striping,” meaning that the data stream is divided into segments or blocks that are stored on separate drives in the RAID. Parity data may be used with data striping, which allows data from a faulty drive or sector(s) to be reconstructed from data on the other data drives in the RAID and the parity data. Another RAID technique is mirroring data on multiple drives within a same RAID set. That is, a copy of a data set is stored/maintained on a separate drive so that if one of the drives goes down, the duplicate data set is immediately available from the mirror drive.
Various prior art RAID implementations have been used to provide increased read performance and data redundancy. By way of example, U.S. Pat. No. 7,225,315 is directed to a file system including a storage system having a plurality of volumes, a volume allocation table adapted to set the plurality of volumes for each directory, a file allocation table that stores attributes and divided block information of the file, a block reading table in which numbers of blocks read out in one reading operation for each volume are respectively set, and a read control module that controls data read from the volume. A read control module, when a read command is received, determines a volume to be read from the volume allocation table. The read control module further determines the number of blocks read for each volume by referring to the block reading table, determines the blocks read for each volume based on the volume, the number of blocks, and the block information, and reads from each volume in parallel.
Despite the advantages that such configurations provide in certain applications, further data reading and recovery features may be desirable in high-bandwidth, high-reliability data storage applications, such as broadcast video applications, for example.